Field
Various communication systems may benefit from appropriate handling of secure data. More specifically, certain packet-based communication systems may benefit from a mechanism to support coordinated packet delivery of one or more encrypted sessions.
Description of the Related Art
Mobile core network, radio network with Mobile Edge Computing (MEC), and wire line network can provide a collection of service enablers for providing Value Added Services (VAS) and can improve network operational efficiency. A typical user may get service based on subscription or category of application traffic types. To differentiate and control traffic based on subscription or various other criteria operators can deploy middle-boxes on their networks.
Depending upon type of service, traffic may pass through one or more middle-box functions deployed in the networks. Operators can deploy middle-boxes on wired and wireless networks and a goal of the middle-box can be to improve operational efficiency for the network and/or to scale the network.
As an example, FIG. 1 illustrates various middle-boxes deployed by operators in a wireless SGi LAN interface. Most commonly used middle-box functions can include Carrier Grade Network Address Translation (CG-NAT), Firewall, Web Optimizer (not shown), Video Optimizer, TCP optimizer, caching server, Load Balancer, Proxy, Analytics, and the like.
FIG. 1 shows deployment scenario of middle-box functions and how different packets go through series of network interfaces. Multiple network functions can be connected or chained to provide a network service. Packets can get different treatment based on the path selected and the middle-box that it encounters. The way middle-boxes are interconnected in SGi LAN can be referred to as service chaining. Using service chaining, operators can create new applications, for example delivering customized services that provide incremental value. Typically, most of the middle-boxes do deep packet inspections to do the flow identification.
Nevertheless, current usage of service chaining and middle-box may not be effective. For example, application service providers (ASPs) have started to deliver their service over encrypted secure socket layer (SSL) traffic. The operator is conventionally unable to inspect the traffic that flows through their networks when it is encrypted in this way. Furthermore, certain classes of middle-boxes operate on HTTP and not encrypted HTTP. Furthermore, there may be several optimizers on a path between device client to application server, and these optimizers may be running without any mutually agreed standards.
More generally, the growing rate of internet traffic encrypted with SSL over access networks has both immediate and long-term impacts on the access networks ecosystem and access technology architectures. Here, the term access network can include both wired and wireless network architectures. Thus, access network can refer to the portion of the end-to-end (E2E or e2e) path between the device and the application server within the operator network.
Though such encryption may increase the e2e security and privacy from the end user point of view, middle-box service providers (MSPs) may be unable to inspect the packet data in the middle. The increasing amount of encryption used on the public internet may thus limit the ability to inspect subscriber flows using traditional deep packet inspection (DPI) technologies.
Operators currently deploy DPI functions or other middle-boxes to analyze network traffic, to profile the subscriber, and to profile the application that flows through their network. There are multiple situations in which traditional DPI may not work and due to which user experience may be affected.
These issues can be illustrated in a variety of ways. For example, a DPI engine can report the usage as part of a flow and can classify each flow into a group of available application classes. Application insights from DPI can be used to create service plans. For example, an operator may be interested in creating a service plan based on usage. With a static service chaining (SC) policy, lack of coordination between ASP and operator and lack of DPI control can put operators in a hard situation to have a dynamic service plan creation. Even the few common reports that were generated for basic service plans will not be available when ASP moves to encrypted session.
In such cases, the application insights may aim to report the following: applications that consume the most data; top twn applications that takes maximum data flow on operator traffic; total data used over a specified time period (week or month) by applications; total mobile data used over a specified time period (week or month); average app data rate (KB/min) by user to create service plans; average foreground app data rate (KB/min) to create service plans; average background app data rate (KB/min) to create service plans; and application quality and performance. The purpose of such reports may be, for example, so that carriers can pinpoint how their top one hundred most used apps are impacting the carrier network and customer experience. There are also many other specific insights that may be sought, with the above merely being examples.
One conventional technique is to attempt to use encryption to by-pass middle-box functions. Some ASPs act as though application client feedback is sufficient for application delivery. Hence, the ASPs may enable encryption to bypass all middle-box and SC function on the access networks. From HTTP DASH protocol usage, it can be seen that user QoE may be compromised in such approaches.
Dynamic configuration of policies in middle-box may be desired by an ASP. For example, an ASP may want to introduce any policy changes dynamically by the ASP. Such an introduction, however, may need to be agreed beforehand between the ASP and the operator. The DPI polices that are currently adopted may be set up in a static or semi-static configuration. This approach may lack flexibility to introduce new services for ASP over the access networks.
Classifying traffic by website URLs alone may have an issue in that URLs do not provide full information on the mechanics of access. Also understanding of protocol behaviors context, user accessing the internet pattern, and type of traffic may need to be available inside the network.
The type of the traffic, for example a protocol like HTTP, FTP, BitTorrent, SIP, RTP, or the like, may need to be known. As a next step, the parameters of that specific protocol, for example for RTP the local IP address, the Registrar IP address, the CALL-ID, and so on, may need to be accessible inside the telecom network. Such information may enable actionable operations such as traffic admission, prioritization and shaping, restriction of access such as parental control, and support for new services and revenue models in the telecom network.
As ASP service is provided over encrypted SSL traffic, the above mentioned information may not be accessible as none of the network elements inside the operator network may be able to inspect the traffic that flows through them.